Java 消息服务

JMS（Java Message Service，Java 消息服务）是 1999 年由 Sun Microsystems 领衔开发的一种访问消息系统的方法，也就是供 Java 程序员使用的面向消息的中间件（Message Oriented Middleware，MOM）。这种基于消息传送的异步处理模型，具有非阻塞的调用特性。发送者将消息发送给消息服务器，服务器会在合适的时候再将消息转发给接收者；发送和接收采用异步方式，这就意味着发送者无须等待，发送者和接收者的生命周期也无需相同，而且发送者还可以将消息传给多个接收者。如此一来，这种异步处理方式就大大提升了应用程序的健壮性、性能和可伸缩性，使数据集成和系统整合工作变得易如反掌，特别是在分布式应用上让同步处理方式望尘莫及。Java 消息服务作为一个与具体平台无关的 API，已经得到了绝大多数 MOM 提供商的支持。

消息传送机制基础

近些年来，系统的复杂性和先进性增长非常显著。现在对系统的可靠性、可伸缩性和灵活性等的要求要比以前更高。为了适应对更好更快的系统日益增长的要求，我们开始利用消息传送机制（Messaging），作为解决这些复杂问题的一种方式。

异构集成（Heterogeneous Integration）是消息传送机制在其中起关键作用的一个领域。越来越多的公司都正面临着在企业内部、跨企业集成异构系统和应用程序的问题。在一家公司或部门内部，会使用 Java EE、Microsoft .NET 等多种技术和平台，这种情况毫不足奇。

消息传送机制还具有异步处理请求的能力，能够减轻或消除系统瓶颈，且能提高系统吞吐量和整体可伸缩性。由于消息传送机制能够实现组件之间的高度去耦，因此，使用这种机制的系统还具有高度的体系结构灵活性和敏捷性。

应用程序到应用程序（Application-To-Application）类型的消息传送系统，在用于业务系统时，通常称为企业消息传送系统（Enterprise Messaging System），或者称为面向消息的中间件（Message Oriented Middleware，MOM）。企业消息传送系统允许两个或更多的应用程序以消息的形式来交换信息。这时，一条消息就是业务数据和网络路由头的一个自包含（Self-Contained）数据包。消息中包含的业务数据可以是任何内容，这取决于业务场景，而且，它通常包含了有关某些业务事务的信息。在企业消息传送系统当中，消息会将另一个系统中的某些事务或事件通知给一个应用程序。

通过使用面向消息的中间件，消息通过网络从一个应用程序传送到另一个应用程序之中。企业中间件产品能够确保消息在应用程序中间的正确分发，这些产品通常提供了对容错和负载均衡、可伸缩性和事务性的支持。

在所有的现代企业消息传送系统中，应用程序通过虚拟通道来交换消息，这些虚拟通道称为目的地。发送一条消息时，是发送到一个目的地（也就是队列或主题），而不是发送到某个特定的应用程序。在这个目的地中，订阅或注册对该目的地感兴趣的所有应用程序都可以接收这条消息。这样一来，接收消息的应用程序和发送消息的应用程序就能够实现去耦。发送者和接收者并非在任何情况下都相互绑定在一起，而且，它们可以在自己认为合适的时候发送和接收消息。

JMS 是一种厂商无关（Vendor Agnostic）的 Java API，它可以供多个不同的企业消息厂商使用。JMS 与 JDBC（Java Datebase Connectivity，Java 数据库连接）非常相似，我们能够重用同样的 API 来访问多种不同的系统。

消息传送机制的优点

消息传送机制能够解决诸多体系结构性挑战。比如说异构集成、可伸缩性、系统瓶颈、并发处理，以及整体体系结构灵活性和敏捷性等。

异构集成

异构平台的通信和集成可能是消息传送机制最为典型的使用范例。许多开源消息传送系统和商业消息传送系统使用了一种集成消息桥（Message Bridge），该桥能够将使用 JMS 的一条消息转换为通用的内部消息格式，以此来实现 Java 和其他语言和平台之间的无缝连接。

从历史上看，在应对异构系统的集成问题方面，已经有许多方法。使用数据库在两个异构系统或应用程序之间来共享信息，这是一种迄今仍在广泛应用的常见方法。远程过程调用（Remote Procedure Call，RPC），也是在不同系统之间共享数据和功能的另一种方法。不过，这些解决方案各自都有优缺点，只有消息传送机制提供的去耦解决方案，能够真正实现跨应用程序或子系统共享数据和功能。还有 Web服务（Web Services），作为异构系统的另一种可能的解决方案脱颖而出。不过 Web 服务在可靠性方面的欠缺，使得消息传送机制成为一种更佳的集成选择。

缓解系统瓶颈

无论何时，只有某个进程跟不上对它访问请求的速度，那么就会产生系统和应用程序的瓶颈问题。系统瓶颈的一个经典例子是：在一个拙劣优化（Poorly Tuned）的数据库中，应用程序和进程在一直等待，直到数据库连接可用或数据库锁被释放为止。在系统的某些地方，系统将出现阻塞，响应会越来越慢，直到最终请求出现超时现象。

而消息传送机制可以用于缓解乃至消除系统瓶颈。与一个同步组件处理众多请求时，众多请求一个接一个地积聚阻塞不同，这时候请求会发送到一个消息传送系统，该系统将该请求分发给多个消息侦听器组件。如此一来，就缓解了单独采用点对点同步连接带来的系统瓶颈，在某些情况下，甚至可以完全消除这些瓶颈。

提高可伸缩性

通过引入能够并发处理不同消息的多个消息接收者，消息传送系统的可伸缩性得以实现。由于消息排队等候处理，队列中的消息数量，或者称为队列深度（Queue Depth），开始逐渐增大。随着队列深度的增大，系统响应时间开始边长，与此同时，吞吐量也会下降。提高系统可伸缩性的一种方法就是，向队列中添加多个并发消息侦听器，以便并发处理更多的请求。

提高系统整体可伸缩性的另一种方法，就是要尽可能地利用系统的异步方式。虽然这看起来像是银弹（Silver Bullet），不过，中间件只能在系统的另一个主要瓶颈——数据库——的实质性限制之内进行水平扩展。

提高最终用户生产率

使用异步消息传送机制还能够提高最终用户的生产率。使用异步消息传送机制，当执行长时间运行请求时，最终用户能够向系统发出一个请求，并立即得到回应，表明该请求已被接收，最终用户可以在系统上继续其他操作。一旦该请求处理完毕，就立即告知最终用户，并将处理回传给最终用户。

通过使用消息传送机制，最终用户就能够以更短的等待时间来完成更多的工作，使得最终用户拥有更高的生产率。

体系结构灵活性和敏捷性

使用消息传送机制，各个子系统、组件，乃至服务都能够被抽象出来，甚至可以达到在对其知之甚少，甚至是一无所知的情况下，即可用客户端组件所取代的程度。

体系结构敏捷性是对不断变化的环境快速响应的能力。使用消息传送机制方式，消息生产者或是客户端组件都不会知道接收组件使用的哪种编程语言或平台，组件或服务位于何处，组件或服务实现的名称是什么，甚至用于访问该组件或服务的是哪种协议。

企业消息传送

企业消息传送的一个关键概念就是：消息是通过网络从一个系统异步传送给其他系统的。异步传送一条消息意味着：发送者不需要等待接收者或处理该消息；它可以自由地发送消息并持续进行处理。

在异步消息传送机制中，应用程序使用一个简单的 API 来构建一条消息，然后再将该消息转发给面向消息的中间件，以便传送给一个或多个的预订接收者。

（图片来源：Java 消息服务）

现在，面向消息的中间件体系结构在其实现方面，范围从依赖消息服务器来执行路由选择的集中式体系结构，一直到将“服务器”处理分发给客户端及其的分散式体系结构，形式可以说是多种多样。在网络传输层，它使用了包括 TCP/IP、HTTP、SSL 和 IP 组播在内的众多协议。根据使用模式的不同，一些消息传送产品则是采用二者混合的方法。

集中式体系结构

使用集中式体系结构的企业消息传送系统，依赖于一台消息服务器（Message Server）。

消息服务器，也称为消息路由器（Message Router）或代理（Broker），它负责从一个消息传送客户端向其他消息传送客户端传送消息。消息服务器可以实现一个发送客户端和其他接收客户端之间的去耦。客户端仅仅会看到消息传送服务器，而不会看到其他客户端，这将允许在不会影响系统整体的情况下添加和删除客户端。

通常，集中式体系结构使用的是一种星型（Hub-And-Spoke）拓扑结构。最简单的例子就是，只有一台集中式消息服务器及其相连的所有客户端。

（图片来源：Java 消息服务）

星型体系结构适合于一个最小数量的网络连接，同时，它仍然允许系统的任何部分和其他部分进行通信。

提示

实际上，集中式消息服务器也可以按照逻辑单元（Logical Unit）方式拓展为一个分布式服务器集群（Cluster）。

分散式体系结构

当前，所有的分散式体系结构都在使用网络层 IP 组播。基于组播的消息传送系统没有集中式服务器。一些服务器功能（持久性、事务和安全险）作为一个客户端的本地部分嵌入进来，而此时消息路由则利用 IP 组播协议委托给网络层。

IP 组播允许应用程序加入到一个或多个 IP 组播组（IP Multicast Group）之中；每个组播组使用一个 IP 网络地址，它将接收到的所有消息重新发布（Redistribute）给组内的所有成员。这样，应用程序就能够向一个 IP 组播地址发送消息，并期望网络层正确地重新发布这些消息。

（图片来源：Java 消息服务）

与集中式体系结构不同，分布式体系结构不需要用于消息路由的服务器，因为网络会自动地处理路由。然而，每个客户端仍然需要具有像服务器那样的其他功能，比如说消息持久性和“一次而且仅仅一次”传送（Delivery）之类的消息传送语义等。

混合体系结构

一个分散式体系结构通常意味着正在使用 IP 组播协议，而一个集中式体系结构则意味着 TCP/IP 在不同组件之间实现通信的基础。一个消息传送系统厂商的体系结构还可能会将这两种方法结合起来。客户端可以使用 TCP/IP 连接到一个守护进程（Daemon Process），它使用 IP 组播组依次和其他守护进程实现通信。

消息传送模型

JMS 支持两类消息传送模型：点对点模型（Point-To-Point，P2P）和发布/订阅模型（Publish-Subscribe，Pub/Sub）。有时候，又称这些消息传送模型为消息传送域。

简而言之，发布/订阅模型设计用于一对多（One-To-Many）消息广播，而点对点模型则设计用于一对一（One-To-One）消息传送。

（图片来源：Java 消息服务）

在 JMS 中，消息传送客户端称为 JMS 客户端（JMS Client），而消息传送系统则称为 JMS 提供者（JMS Provider）。一个 JMS 应用程序是由多个 JMS 客户端和（通常是）一个 JMS 提供者所组成的业务系统。

此外，生产消息的 JMS 客户端称为消息生产者（Message Producer），而接收消息的 JMS 客户端则称为消息消费者（Message Consumer）。一个 JMS 客户端可以既是消息生产者，又是消息消费者。

点对点模型

点对点消息传送模型允许 JMS 客户端通过队列（Queue）这个虚拟通道来同步和异步发送、接收消息。在点对点模型中，消息生产者称为发送者（Sender），而消息消费者则称为接收者（Receiver）。一般来说，点对点模型是一个基于拉取（Pull）或基于轮询（Polling）的消息传送模型，这种模型从队列中请求消息，而不是自动地将消息推送到客户端。点对点消息传送模型的一个突出特点就是：发送到队列的消息被一个而且仅仅一个接收者所接收，即使可能有多个接收者在一个队列中侦听同一消息时，也是如此。

点对点消息传送模型既支持异步“即发即弃（Fire And Forget）”消息传送方式，又支持同步请求/应答消息传送方式。点对点消息传送模型比 Pub/Sub 模型具有更强的耦合性，发送者通常会知道消息将被如何使用，而且也会知道谁将接收该消息。

点对点模型支持负载均衡，它允许多个接收者侦听同一队列，并以此来分配负载。点对点模型还具有其他优点，比如说，队列浏览器允许客户端在消费其消息之前查看队列内容——在发布/订阅模型中，并没有这种浏览器的概念。

发布/订阅模型

在发布/订阅模型中，消息会被发布到一个名为主题（Topic）的虚拟通道中。消息生产者称为发布者（Publisher），而消息消费者则称为订阅者（Subscriber）。与点对点模型不同，使用发布/订阅模型发布到一个主题的消息，能够由多个订阅者所接收。有时候，也称这项技术为广播（Broadcasting）消息。每个订阅者都会接收到每条消息的一个副本。总地来说，发布/订阅消息传送模型基本上是一个基于推送（Push）的模型，其中消息自动地向消费者广播，它们无序请求或轮询主题来获得新消息。

发布/订阅模型的去耦能力要比 P2P 模型更强，消息发布者通常不会意识到有多少个订阅者或那些订阅者如何处理这些消息。

在发布/订阅消息传送模型内部，有多种不同类型的订阅者。非持久订阅者是临时订阅类型，它们至少在主动侦听主题时才接收消息。而另一方面，持久订阅者将接收到发布的每条消息的一个副本，即便在发布消息，它们处于“理线”状态时也是如此。另外还有动态持久订阅者和受管的持久订阅者等类型。

JMS API

JMS 自身并不是一种消息传送系统；它是消息传送客户端和消息传送系统通信时所需接口和类的一 个抽象。与 JDBC 抽象（JDBC abstract）访问关系数据库、JNDI 抽象访问命名和目录服务的方式一样，JMS 抽象可以访问消息提供者。使用 JMS，应用程序的消息传送客户端可以实现跨消息服务器产品的移植。

JMS API 可以分为 3 个主要部分：公共 API、点对点 API 和发布/订阅 API。在 JMS 1.1 中，公共 API 可被用于向一个队列或一个主题发送消息，或从其中接收消息。点对点 API 专门用于使用队列的消息传送，而发布/订阅 API 则专门用于使用主题的消息传送。

在 JMS 公共 API 内部，和发送和接收 JMS 消息有关的 JMS API 接口主要有 7 个：

• ConnectionFactory
• Destination
• Connection
• Session
• Message
• MessageProducer
• MessageConsumer

在这些公共接口中， ConnectionFactory 和 Destination 必须使用 JNDI（遵照 JMS 规范要求）从提供者处获得。其他接口则可以通过工厂方法在不同的 API 接口中创建。举例来说，一旦有了一个 ConnectionFactory，就可以创建一个 Connection。一旦有了一个 Connection，就可以创建一个 Session。而一旦有了一个 Session，就可以创建一个 Message、MessageProducer 和 MessageConsumer。

（图片来源：Java 消息服务）

在 JMS 中，是 Session 对象保存着用于消息传送的事务性工作单元（Transactional Unit），而不是 Connection 对象。这和 JDBC 不同，JDBC 中是 Connection 对象保存事务性工作单元。这就意味着在使用 JMS 时，一个应用程序通常只会有一个 Connection 对象，但是它可以有一个 Session 对象池。

点对点 API

一旦弄懂了 JMS 的公共 API，JMS API 的其余部分就非常容易类推和理解了。点对点消息传送模型 API 特指 JMS API 之内基于队列的接口。下面是用于向一个队列发送和从一个队列接收消息的接口：

• QueueConnectionFactory
• Queue
• QueueConnection
• QueueSession
• Message
• QueueSender
• QueueReceiver

与在 JMS 公共 API 中一样，QueueConnectionFactory 和 Queue 对象必须通过 JNDI 从 JMS 提供者处获得（按照 JMS 规范的要求）。请注意：大多数接口名称仅仅是在公共 API 接口名称之前添加 Queue 一词而已。不同之处在于，这里是称为 Queue 的 Destination 接口，而 MessageProducer 和 MessageConsumer 接口则分别称为 QueueSender 和 QueueReceiver。

（图片来源：Java 消息服务）

一般来说，使用点对点消息传送模型的应用程序将使用基于队列的 API，而不是使用公共 API。

发布 / 订阅 API

由于基于主题的 JMS API 类似于基于队列的 API，因此在大多数情况下， Queue 这个词会由 Topic 取代。发布/订阅消息传送模型内部使用的接口如下：

• TopicConnectionFactory
• Topic
• TopicConnection
• TopicSession
• Message
• TopicPublisher
• TopicSubscriber

请注意：除了 TopicPublisher 和 TopicSubscriber 不同以外，发布/订阅域中的接口和 P2P 域中的那些接口名称基本类似。发布/订阅模型使用主题、发布者和订阅者这些术语，而 P2P 模型使用的则是队列、发送者和接收者。

（图片来源：Java 消息服务）

实际场景

面向服务体系结构

面向服务体系结构（Service Oriented Architecture，SOA）作为一种体系结构体系，定义了从对应的企业服务实现中抽象出来的业务服务。

在需要将业务服务从其底层实现中完全抽象出来的 SOA 内部构建抽象层时，消息传送是一种极好的手段。使用消息传送机制，业务服务无须关心对应的实现服务位于何处、使用哪种语言编程、在哪种平台上部署，甚至不需要关心实现服务的名称。

事件驱动体系结构

事件驱动体系结构（Event Driven Architecture，EDA）作为一种体系结构体系，它建立在下列前提之上：进程和事件编排是动态的和非常复杂的，因而通过一个中央编排组件来控制或实现是不可行的。当系统中发生了一个活动时，该进程将向整个系统发送一个事件，以此指示发生了一个活动（一个事件）。这个事件接下来可能会启动（Kick Off）其他进程，这些进程又可以依次启动附加的进程，所有进程都会相互去耦。

消息传送机制是基于事件驱动体系结构系统的基础。通常来说，事件一般是以空负载（Empty Payload）消息的模式来实现的，这些消息会在消息头中包含和事件有关的一些信息，尽管某些消息会将应用程序数据作为事件的一部分进行传送。毫不足奇的是，基于 EDA 的体系结构大多使用发布/订阅模型，作为在系统内部广播事件的手段。

异构平台集成

大多数公司，经由合并、收购、移植或错误决策的诸多因素组合，最终会拥有种类繁多的异构业务支撑平台、产品和语言。显然，集成这些平台是一项挑战性极强的任务，特别是相关标准也在持续不断地发展和演变之中。消息传送机制在这些异构平台相互通信之中起到了关键作用，无论这些平台是 Java EE 或 Microsoft .NET 还是 Java EE 和 Tuxedo C++ 等。

企业应用集成

大多数成熟的组织都同时拥有遗留（Legacy）应用系统和新的应用系统，这些系统都是独立实现的，而且无法实现互操作。很多时候，各个组织都会有将这些应用系统集成起来的强烈需求，以便它们能够在大规模企业运行中共享信息并实现协作。这些应用系统的集成通常称为企业应用集成（Enterprise Application Integration，EAI）。

企业到企业

历史上，企业曾使用电子数据交换（Electronic Data Interchange，EDI）系统来交换数据。数据严格使用固定的格式，通过专用增值网络（Value Added Network，VAN）来实现交换。这种接入的成本很高，而且数据通常是以批处理的方式，而不是以实时业务事件的方式来进行交换的。

因特网、XML 和现代消息传送系统已经从根本上改变了在如今称为企业到企业（Business-to-Business，B2B）的系统中，如何进行业务数据交换和交互的状况。使用消息传送系统是现代 B2B 解决方案的主流趋势，因为它允许各个组织相互协作，而无须将它们的业务系统紧密集成起来。

地理分散

如今，很多公司在地理上都是分散的。所有的砖墙加灰泥式的（Brick-And-Mortar）传统实体公司、鼠标加灰泥式的（Click-And-Mortar）新型公司及时兴的网络化（Dot-Coms）公司都面临着和企业系统地理分散有关的诸多问题。JMS 消息传送系统能够确保地理上分散的业务数据交换的安全性和可靠性。

信息广播

拍卖网站、股票报价服务和证券交易，所有这些应用都必须将数据以一对多的方式推送给堪称海量的接收者。在许多情况下，广播信息都需要各个接收者逐一选择路由和过滤。当输出信息要以一对多的方式进行传送时，经常要将对这种信息的响应发回给广播者。这是企业消息传送非常适用的另一种情况，因为 Pub/Sub 模型可以用于发布消息，而 P2P 模型则可以用于响应。

在这些情况下，传送可靠性的选择成了关键因素。举例来说，在广播股票报价时绝对地保证信息传送，这可能并不是最重要的，因为同一股票代码很可能会在较短的时间间隔内进行另一次广播。然而，在交易者通过购买订单对报价做出响应的情况下，以保证的（Guaranteed）方式返回响应是至关重要的。此时，需要综合利用消息传送机制的可靠性，因为发布/订阅模型分发速度很快但并不可靠，而使用点对点模型从交易者处购买订单则是非常可靠的。JMS 和企业消息传送为 Pub/Sub 和 P2P 这两种模型都提供了不同程度的可靠性。

构建动态系统

在 JMS 中，发布/订阅主题和点对点队列是集中管理的，并都称为 JMS 受管对象。应用程序和另一个应用程序通信时，并不用知道各个主题或队列的网络位置；它仅仅将主题和队列对象作为标识符使用而已。使用主题和队列为 JMS 应用程序提供了一定程度的位置透明性和灵活性，这使得在一个企业系统中添加和删除参与者成为可能。

RPC 和异步消息传送

RPC（Remote Procedure Call，远程过程调用）是通常用于描述分布式计算模型的术语，现在 Java 和.NET 这两种平台都在使用这个术语。基于组件的体系结构，比如企业级 JavaBean(Enterprise JavaBeans，EJB），就是建立在这个模型基础之上的。对于许多应用程序来说，基于 RPC 的技术已经是，并且将继续是切实可行的解决方案。不过，企业消息传送模型在特定类型的分布式应用程序中表现更为出色。

紧密耦合的 RPC

紧密耦合的 RPC 模型最为成功的一个领域就是构建 3 层或 n 层应用程序。在这个模型中，表示层（第 1 层）使用 RPC 和中间层（第 2 层）的业务逻辑进行通信，访问位于后端（第 3 层）的数据。Sun Microsystems 公司的 J2EE 平台和 Microsoft 公司的 .NET 平台是这种体系结构最为先进的范例。

使用 J2EE、JSP 和 Servlet 描述的是表示层，而企业级 JavaBean(EJB）则是中间层。抛开平台不论，这些系统使用的核心技术是基于成为定义通信范例的 RPC 的中间件。

RPC 试图模仿在一个进程中运行的某个系统的行为。在调用一个远程过程时，调用者将被阻塞，直到该过程完成并将控制权返回给调用者。从开发者的角度看，这种同步模型使得该系统就好像运行在一个进程当中。这些工作会依次完成，同时确保以预定顺序完成。RPC 同步的本质特性，将客户端（进行调用的软件）和服务器（为该调用服务的软件）二者紧密耦合在一起。因为客户端已被阻塞，所以它无法继续进行工作，直到服务器做出响应为止。

RPC 紧密耦合的本质特性导致出现了相互高度依赖的系统，其中一个系统的失效会对其他系统产生立竿见影的弱化影响。正是 RPC 系统的同步、紧密耦合、相互依赖等本质特性，使得子系统中出现的故障最终会导致整个系统的失效。就像在“系统对系统”场景中那样，当 RPC 紧密耦合的本质特性不再适用时，消息传送机制为此提供了另一种选择方案。

提示

像 CORBA（Common ObjectRequest Broker Architecture，公共对象请求代理体系结构）单向调用这种多线程的、松散的 RPC 机制也是一种选择，不过，这些解决方案自身非常复杂，而且它们还需要成熟完善的开发。当没有“明智地”使用线程时，它们的开销很大，而且在出现故障的情况下，CORBA 单向调用仍然需要进行应用程序级（Application-Level）错误处理。

企业消息传送

各个子系统在可用性方面存在的问题，并不是使用面向消息的中间件所带来的后果。消息传送机制的一个基本思想就是：规定应用程序之间的通信应该采用异步方式。将各部分连接在一起的代码会假定这是一条单向消息，它不需要立即从另一个应用程序那里得到响应。换句话说，也就是没有出现阻塞现象。一旦一条消息被发出，消息传送客户端就能够转向其他任务；它不必等待对这条消息的响应。这是 RPC 和异步消息传送之间的主要区别，而且，它对于理解消息传送系统的优点来说至关重要。

在网络化系统中会出现局部故障，这是一个不可避免的事实。其中的一个系统，可能会在其连续运行期间的某个时刻，发生不可预测的故障，或者需要停机。这种现象可能会由于内部系统和合作系统地理上的分散而被进一步放大。考虑到这个因素，JMS 提供了保证传送（Guaranteed Delivery）方式，它可以确保即便发生了局部故障，预定消费者最终也会接收到这条消息。

保证传送使用的是一种“保存并转发（Store And Forward）”的机制，这就意味着，如果预定消费者当前并不可用，底层消息服务器就会将输入的消息写到一个持久存储器（Persistent Store）之中。随后，当该接收应用程序变为可用时，“保存并转发”机制会把预定消费者在不可用时错过的所有消息传送给它们。

（图片来源：Java 消息服务）

概括来说，JMS 不仅仅是另外一种事件服务。它的设计涵盖了范围极广的企业应用程序，包括 EAI、B2B 和推送模型等。通过异步处理、“保存并转发”及“保证传送”机制，它为保持业务应用程序连续运行并实现不间断服务提供了很高的可用性。它还通过发布/订阅功能和点对点功能，提供了集成灵活性。通过位置透明和管理控制，它提供了一种健壮的、基于服务的体系结构。而且，最重要的是，它非常易于学习和使用。